LGTM. Reviewed the lock_wait_timeout propagation from session/txn options into lock options, local and remote lock wait handling, async waiter timeout path, and related tests. No blocking issues found.

I think there is still a real multi-CN/session-semantics hole here. lock_wait_timeout is supposed to behave like a session variable, but on the remote-CN lock path it can get stuck at the value captured when the transaction was created.

The flow is:

• frontend copies lock_wait_timeout into TxnOptions only when the txn is created (pkg/frontend/txn.go:428-434);
• lockop.lockWaitTimeout() prefers the current process resolver, but falls back to TxnOptions when that resolver is unavailable (pkg/sql/colexec/lockop/lock_op.go:789-809);
• remote processes reconstructed from ProcessInfo do not carry a resolve-variable function or arbitrary session sysvars — only basic session info such as user/host/database/version/timezone is serialized (pkg/vm/process/process_codec.go:48-100).

So if a user does something like BEGIN; SET SESSION lock_wait_timeout = 1; ... and the later locking statement runs on a remote CN, the local path can see the new 1-second setting, but the remote path falls back to the stale txn-start value from TxnOptions (possibly the default 1 year). That means the same session-level change behaves differently depending on whether the lock is local or remote, which is exactly the kind of wait this PR is trying to fix.

I'd like to see the remote path get the current session value as well (or the feature/documentation explicitly narrowed to txn-start snapshot semantics), plus a test that changes lock_wait_timeout after BEGIN and then exercises a remote lock wait.

Re-reviewed the latest head from the session-semantics and unhappy-path angle.

The previous blocker I raised looks addressed now:

• BuildProcessInfo now snapshots the current lock_wait_timeout into pipeline.SessionInfo.LockWaitTimeout, so remote CN processes decoded from ProcessInfo can see the current statement/session value instead of falling back to the txn-start TxnOptions value.
• lockop.lockWaitTimeout() now prefers the current resolver, then decoded SessionInfo.LockWaitTimeout, then the txn option fallback. That covers both local execution and remote-process execution.
• The remote async waiter path now enforces LockWaitTimeout with a precise timer instead of relying only on the coarse lazy check.
• Regression coverage includes the case I was worried about: BEGIN; SET SESSION lock_wait_timeout = 1; ... followed by a remote lock wait.

Local checks:

git diff --check origin/main...HEAD
go test ./pkg/lockservice -run 'TestLockWaitTimeout|TestRemoteLockWaitTimeout|TestRetryRemoteLockError' -count=1
go test ./pkg/txn/client -run 'TestWithTxnLockWaitTimeout' -count=1
git merge-tree --write-tree HEAD origin/main

Those passed. I also attempted the focused pkg/sql/colexec/lockop and pkg/vm/process tests, but this local environment cannot compile those packages because required CGO headers are missing (usearch.h, xxhash.h), so I am not treating that as a test failure. CI is green on the PR.

LGTM.